Method and apparatus for topology management for handovers in heterogeneous networks

ABSTRACT

A method comprises receiving a measurement report, the measurement report containing information from a user equipment, the information being associated with a desired local Radio Access Network (RAN) cell to which the user equipment is to hand-in; and utilizing the information in the measurement report to disambiguate at least one target local RAN and cell from a plurality of local RANs and cells, the at least one target local RAN and cell including the desired local RAN cell.

RELATED APPLICATIONS

This application claims priority under 35 U.S.C. §119(e) to U.S.Provisional Patent Application No. 61/521,930, titled METHOD ANDAPPARATUS FOR TOPOLOGY MANAGEMENT FOR HANDOVERS IN HETEROGENEOUSNETWORKS, filed Aug. 10, 2011, incorporated herein by reference in itsentirety for all purposes.

TECHNICAL FIELD

The present invention relates to communication networks, and moreparticularly, to procedures for achieving seamless hand-in from amacrocellular network into an underlay local area Radio Access Network(RAN).

BACKGROUND

Cellular networks have traditionally been deployed in a homogenousmanner. For example, a typical cellular network may comprise a pluralityof macrocells that are fairly uniform in the coverage areas theysupport. In the case of 3^(rd) Generation Partnership Project (3GPP)Universal Mobile Telecommunications System (UMTS) networks, each ofthese macrocells is connected to a Radio Network Controller (RNC). TheRNC generally effectuates radio resource management, as well as somemobility management functionality, such as facilitating handover,maintaining device state, and supporting layer 2 data-plane protocols.

There are some exceptions to the uniform deployment paradigm describedabove, such as picocell and femtocell networks that are deployed inconjunction with an overarching macrocellular network. That is,picocells and femtocells, which may be considered small cellular basestations or access points, connect to a service provider's macrocellularnetwork via broadband connections, allowing the macrocellular network tobe extended either for capacity augmentation or for extending thecoverage (e.g., indoors). These picocells and femtocells may be deployedin the same frequency channel as the macrocellular network, in whichcase they are referred to as co-channel deployments, or in a differentfrequency channel, in which case they are referred to as dedicatedchannel deployments.

For example, in-building Distributed Antenna Systems (DASs), powered bypicocells, are deployed sporadically within the shadow of themacrocellular network. These picocells are typically manuallyprovisioned to connect to the same RNC that is serving the nearbymacrocells, thus facilitating mobility in and out of the coverage areaof the picocell. In recent years, there has been a rapid growth ofconsumer femtocells, which are typically standalone entities serving alimited area. Each of these consumer femtocells is typically connectedto a femtocell gateway that interfaces the femtocells with the corenetwork of the cellular service provider. In some cases, the gatewayalso facilitates “hand-out” of a user “in a call” from the femtocell tothe macrocellular network. The gateway may also use a white list ofInternational Mobile Subscriber Identities (IMSIs) provisioned perfemtocell along with user equipment (UE) measurements to facilitate“hand-in” of a user into a particular femtocell. However, commercialsolutions that do not require a white list of IMSIs for hand in to afemtocell do not appear to exist.

SUMMARY

Various aspects of examples of the invention are set out in the claims.

According to a first aspect of the present invention, a method comprisesreceiving a measurement report, the measurement report containinginformation from a user equipment, the information being associated witha desired local Radio Access Network (RAN) cell to which the userequipment is to hand-in; and utilizing the information in themeasurement report to disambiguate at least one target local RAN andcell from a plurality of local RANs and cells, the at least one targetlocal RAN and cell including the desired local RAN cell.

In one embodiment, the measurement report is received at a local RANgateway from a source RAN. The method may further comprise receiving, atthe local RAN gateway, a relocation required message from a source RAN,the relocation required message containing the measurement report;sending a relocation request to the at least one disambiguated targetlocal RAN and cell; receiving a relocation acknowledgement from thedesired local RAN cell; and forwarding the relocation acknowledgement toa core network.

The method may further comprise receiving at the local RAN gateway fromthe plurality of local RANs and cells, timing information relating totiming differences between the cells of the plurality of local RANs andcells and neighboring cells measured during a radio environmentmonitoring process. The method may further comprise periodicallyupdating the timing difference information.

In one embodiment, the information in the measurement report used todisambiguate at least one target local RAN and cell is a timinginformation associated with the desired RAN cell. The timing informationmay include a timing difference between a cell in the current active setof the user equipment and the desired RAN cell.

In another embodiment, the timing information includes a chip offset ofthe desired RAN cell. The method may further comprise multicasting thereceived timing information to the plurality of local RANs and cells,wherein each of the plurality of local RANs and cells autonomouslydetermines whether to at least one of participate in the handover orrestrict the plurality of cells that are to participate in the handover.

In one embodiment, the method further comprises configuring a specifictiming offset range for each of the plurality of local RANs and cells.The specific timing offset range may be configured by a local RANgateway as a part of a gateway registration process.

In one embodiment, utilizing the information comprises disambiguatingthe target local RAN and cell based on the information in themeasurement report and timing information relating the target local RANand cell. The utilizing of the information to disambiguate the targetlocal RAN and cell is performed at a source RAN.

In one embodiment, the method further comprises determining, by thesource RAN, a desired local cell within a current RAN; and performing asoft handover without involving a local RAN gateway of the current RAN.

In another embodiment, the method further comprises determining, by thesource RAN that a desired local RAN and cell belongs to a second localRAN linked to a current local RAN via an Iur link; and performing a softhandover over the Iur link without involving a local RAN gateway of thecurrent local RAN.

In one embodiment, the information in the measurement report used todisambiguate at least one target local RAN and cell is a signal-to-noiseratio (SNR) of a pilot signal broadcast by the desired RAN cell.

In one embodiment, the information in the measurement report used todisambiguate at least one target local RAN and cell is a received signalcode power (RSCP) of a pilot signal broadcast by the desired RAN cell.

In one embodiment, the information in the measurement report used todisambiguate at least one target local RAN and cell is a pathloss of apilot signal broadcast by the desired RAN cell.

In a second aspect of the invention, a method comprises receiving, atone of a plurality of local Radio Access Networks (RANs), a multicastmessage from a local RAN gateway, the multicast message including timinginformation related to each of the plurality of local RANs, theplurality of local RANs being candidates for a hand-in of a userequipment; and determining, by the one of the plurality of local RANs,whether to at least one of participate in the handover or restrict theplurality of cells that are to participate in the handover, based on thetiming information.

In a third aspect of the invention, an apparatus comprises a processor;and a memory including computer program code. The memory and thecomputer program code are configured to, with the processor, cause theapparatus to perform at least the following: receive a measurementreport, the measurement report containing information from a userequipment, the information being associated with a desired local RadioAccess Network (RAN) cell to which the user equipment is to hand-in; andutilize the information in the measurement report to disambiguate atleast one target local RAN and cell from a plurality of local RANs andcells, the at least one target local RAN and cell including the desiredlocal RAN cell.

In a fourth aspect, an apparatus comprises a processor; and a memoryincluding computer program code. The memory and the computer programcode are configured to, with the processor, cause the apparatus toperform at least the following: receive, at one of a plurality of localRadio Access Networks (RANs), a multicast message from a local RANgateway, the multicast message including timing information related toeach of the plurality of local RANs, the plurality of local RANs beingcandidates for a hand-in of a user equipment; and determine, by the oneof the plurality of local RANs, whether to at least one of participatein the handover or restrict the plurality of cells that are toparticipate in the handover, based on the timing information.

In a fifth aspect, a computer program product, embodied on anon-transitory computer-readable medium, comprises computer code forreceiving a measurement report, the measurement report containinginformation from a user equipment, the information being associated witha desired local Radio Access Network (RAN) cell to which the userequipment is to hand-in; and computer code for utilizing the informationin the measurement report to disambiguate at least one target local RANand cell from a plurality of local RANs and cells, the at least onetarget local RAN and cell including the desired local RAN cell.

In a sixth aspect, a computer program product, embodied on anon-transitory computer-readable medium, comprises computer code forreceiving, at one of a plurality of local Radio Access Networks (RANs),a multicast message from a local RAN gateway, the multicast messageincluding timing information related to each of the plurality of localRANs, the plurality of local RANs being candidates for a hand-in of auser equipment; and computer code for determining, by the one of theplurality of local RANs, whether to at least one of participate in thehandover or restrict the plurality of cells that are to participate inthe handover, based on the timing information.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of example embodiments of the presentinvention, reference is now made to the following descriptions taken inconnection with the accompanying drawings in which:

FIG. 1 is an exemplary call flow for SRNS relocation and hard handover;

FIG. 2 is an exemplary call flow for hand-in into a UMTS ERAN;

FIG. 3 is a flow chart illustrating a process in accordance with anembodiment of the invention;

FIG. 4 is a flow chart illustrating a process in accordance with anembodiment of the invention; and

FIG. 5 is a flow chart illustrating a process in accordance with anembodiment of the invention.

DETAILED DESCRIPTON OF CERTAIN EMBODIMENTS

Certain issues arise during handovers in a Wideband Code DivisionMultiple Access (WCDMA) network. For example, handovers from a macrocellto a femtocell would require disambiguation of a particular PrimaryScrambling Code (PSC) reported by a UE from a plurality of availablePSCs. Additionally, although partial solutions exist with regard toaddressing hand-in issues in the consumer femtocell context, suchsolutions are not scalable.

FIG. 1 illustrates a typical, exemplary call flow for a Serving RadioNetwork Subsystem (SRNS) Relocation procedure with hard handover in aWCDMA network. In a macrocellular network, such a procedure is attemptedin situations when there is no Iur interface between the source andtarget RNCs. The same concepts can be extended to mobility in variouscontexts, including but not limited to the following: between amacrocellular network and a local area network such as an Enterprise RAN(ERAN); and between two local RANs/ERANs, between two independentlymanaged macrocellular networks. It should be noted that throughout thisspecification, the term “ERAN” may be used to refer to any local areanetwork that is deployed in conjunction with a macrocellular network,either on the same frequency, or deployed in a distinct frequency.

As illustrated in FIG. 1, the entire procedure is triggered by a UEmeasurement report message sent from a UE 100 to a source RNC (SRNC) 120that informs the SRNC 120 of the presence of a target cell 150, eitheron the same frequency in the case of a co-channel deployment, or on aseparate frequency in the case of an inter-frequency deployment. Arelocation required message is sent from the SRNC 120 to the CoreNetwork (CN) 130, whereupon the CN 130 forwards a relocation requestmessage to the target RNC (TRNC) 140. The TRNC 140 and target cell 150exchange relocation configuration request and response information, andthe TRNC 140 sends a relocation acknowledgement message to the CN 130.The CN then transmits a relocation command message to the SRNC 120,where the SRNC 120 then sends a Radio Resource Control (RRC) messageRadio Bearer Reconfiguration (RBR) to establish the uplink and downlinkshared channels with the UE 100. The UE then syncs to the target cell150, i.e., switches from the old Radio Link (RL) to the new RL, and thesource cell 110 sends an RL failure message to the SRNC 120. The TRNC140 indicates to the CN 130 that relocation is complete, the Iuinterface is released pursuant to an Iu Release message from the CN 130to the SRNC 120, the RL is deleted in a request and response exchangebetween the SRNC 120 and the source cell 110. Lastly, the SRNC 120 sendsan Iu Release Complete message to the CN 130. The target cell isinitially identified from the PSC of the cell that is reported by the UEin the measurement report. Thus the SRNC needs to know how to uniquelydisambiguate the target cell from the PSC reported by the UE. In macronetworks, this is typically done manually through the process of networkplanning and provisioning of the neighbor lists on the SRNC.

In UMTS systems, all handovers are network controlled, but may betriggered by UE measurements. That is, UEs typically detect and measurethe strength of PSCs of other cells and communicate these PSCs back tothe SRNC in the form of a measurement report. Different kinds ofmeasurement events are used depending on whether these measurements areintra-frequency or inter-frequency. It should be noted that additionalconsiderations exist for inter-frequency measurements, including therequirement on the UE to be in Compressed Mode in order to tune itsreceiver to another frequency.

There is a hierarchy of identifiers that may be used by differententities in any UMTS network. There are three such identifiers relevantto mobility that can be represented as a triplet (PSC, cell identifier(CellID), RNCID). In a UMTS ERAN, there are only 512 PSCs (ranging from0 to 511) and are typically reused in a network deployment. However, theCellldentifier and the RNCID have larger number spaces and are typicallypair-wise unique within a single operator's deployment.

Typically, in a homogenous network, the RNC is fully aware of theneighbor topology, i.e., the RNC has full knowledge of each cell and theother neighbors (from an RF perspective) of that cell. This neighborlist information, including the triplet (PSC, CellID, RNCID), isactually transmitted by each cell in the system broadcast messages. Thisneighbor list information is used by the UE to prioritize PSC detectionin anticipation of handover. When a neighbor is detected as beingsufficiently strong, its PSC is reported by the UE in a measurementreport.

In a homogenous network, the entire neighbor topology is managed andfully determined. The RNC is in a position to map the PSC reported by aUE to a full triplet (PSC, CellID, RNCID) since it is aware of the cellsin the UE's active set, and the neighboring cells in that location.Therefore, the RNC is able to fully disambiguate the PSC andconclusively identify the target cell for handover. This approach worksif the topology can be manually determined and maintained following anychanges in the deployment. However, as previously indicated, thisapproach does not scale well. For example, considering a deployment of alarge number of femtocells in the shadow of a macrocellular network,handovers from a macrocell to a femtocell would require disambiguationof a PSC reported by a UE. In principle, this would not be a problem ifevery femtocell had a unique PSC. However, because of the limited rangeof PSCs imposed by physical layer processing and UMTS signalingconstraints, as well as the logistics of managing PSCs used byfemtocells in neighbor lists broadcast by macrocells, it is not feasibleto assign a unique, or even a locally unique PSC per femtocell. Even ina “reasonable” femtocell deployment, it is likely that severalfemtocells within the shadow of a single macrocellular sector areassigned the same PSC.

Alternatively, the disambiguation can be fully performed by the UE as itreads the neighbor lists broadcast by any cell that it connects with,and can map a detected PSC to the triplet (PSC, CellID, RNCID) andreport this triplet back. In pre-Release 8 UMTS specifications, though,only the PSC is required to be reported, and most, if not all, UEimplementations comply only with this minimum requirement. In theconsumer femtocell context, some partial solutions have beenproposed/deployed to address the hand-in issue, one such solution usingthe Closed Subscriber Groups (CSG) attribute associated with a user toattempt a hand-in to that user's registered home femtocell if theappropriate PSC is reported. However, such solutions are not scalablebeyond the strict CSG scenario.

Various embodiments, as described herein, seek to address “hand-in”issues associated with local area networks such as, UMTS ERAN, consumerfemtocells, etc., by disambiguating a reported PSC and uniquelydetermining a hand-in target localRAN/cell. The various embodimentsutilize a complementary network entity referred to as a local RANGateway (GW), which may be, e.g., a modified Iuh or femto gateway. Inaccordance with various embodiments, the local RAN gateway is positionedwithin the operator network and serves to aggregate a large number oflocal RANs.

In certain embodiments, all local RANs deployed for a particularoperator on a specific channel are assigned a set of “boundary PSCs.”This concept is analogous to sets of “femto PSCs” that are used incommercial femtocell deployments. In the case of consumer femtocelldeployments, these boundary PSCs may be the only ones assigned. In thecase of more complex local RANs, such as an ERAN, the boundary PSCs maybe used in addition to other PSCs.

In some UMTS networks, Neighbor lists of all the macrocells in themacrocellular network are pre-provisioned with these boundary PSCs.Specifically, these PSCs are mapped to cells that are associated with atarget RNC that is actually the local RAN GW. The target cell ID is notrelevant and can be any value. The pre-provisioning can be done withoutapriori knowledge of whether a local RAN is presently deployed under thecoverage area of the macrocells. This makes it a one-time provisioningexercise on the macro network and providing future compatibility.

It is important for a UE to expeditiously detect cells of a local RANupon entry into the area covered by this RAN. A local RAN, such as anERAN, may choose to use boundary PSCs on some cells in order tofacilitate this detection. Additionally, boundary PSCs may also besprinkled through the interior of the ERAN so that a UE in the ERANcoverage area will discover a boundary PSC with high probability. Inaddition to the boundary PSCs, the ERAN may also utilize other PSCs thatare not known to the macrocells in the vicinity of the ERAN deployment.This provisioning step is required for good cell reselection performanceof the UE as it enters the coverage area of the ERAN. The selection ofthe cells for use with the boundary PSCs may be either manual or learnedvia automated means, such as estimation of user density, mobility, RFtopology of the cells, etc.

UEs in an active session (referred to as Cell DCH in UMTS) on the macrocell are configured by the macrocell to measure and report the PSCs usedby the neighbor cells, which will typically include the boundary PSCsset aside for use in local RANs. Upon reception of a report from the UEthat requires a handover to a “local RAN boundary PSC,” a macro RNC willmap the target RNCID corresponding to this PSC to the local RAN GW priorto initiating an SRNS Relocation Required message.

FIG. 2 is an exemplary call flow for hand-in into a local RAN, such as aUMTS ERAN, in accordance with one embodiment of the present inventionthat utilizes a multicast with predefined radio bearer configurationsapproach. This embodiment is described from the point at which a macroRNC 220 has received a UE measurement report message from a UE 200indicating the presence of a cell (e.g., one of multiple target cells260 a-m) that is identified to be a well-known “ERAN boundary PSC.” Themacro RNC 220 then sends an SRNS Relocation Required message to the CN230 (e.g., a mobile switching center (MSC) or Serving GPRS Support Node(SGSN)), which sends a Relocation Request message to the local RAN GW240, identified as the target RNC for the reported PSC/target cells 260a-m.

In the nominal call flow analogous to that illustrated in FIG. 1, thelocal RAN GW 240 would theoretically just forward the Relocation Requestmessage to a specific target ERAN. However, because the “local RANboundary PSCs” may be re-used in each of the deployed ERANs, the localRAN GW is not in a position to disambiguate a specific target localRAN/ERAN. Thus, the local RAN GW 240 multicasts the SRNS RelocationRequest to multiple ERANs 250 a-n. Additionally, since the “local RANboundary PSC” may be reused within each ERAN as well, multiple cellswith the same PSC as indicated in the SRNS Relocation Request, may beconfigured per ERAN.

The number of cells configured in a given local RAN may simply be allthe cells with the given PSC, or some subset of it. The selection of thesubset of cells to participate in the handin event may be manual orautomatically discovered.

It should be noted that during a “cleanup” phase, as will be discussedin greater detail below, any radio links (i.e., cells) that did notreceive the UE's uplink signal may be torn down to ensure that aninbound handover is terminated on a single cell.

In a standard implementation, a target RNC would unilaterally andautonomously generate a response, i.e., a Reloc Request Ack. The variousparameters chosen for the post-handover configuration (airlink, RLC,ciphering, etc.) signaled in this response are typically chosenautonomously by the target RNC according to internal rules. However,this approach conflicts with the aforementioned multicast procedure.This is because each target ERAN 250 a-n would generate a differentresponse from its peers, thus making it infeasible for the local RAN GW240 to synthesize a single configuration to be echoed back to the SRNCin the Relocation Command. Thus, a mechanism is provided thatcoordinates the actions of the local RAN GW 240 with the RNC software ineach of the target ERANs 250 a-n so that a harmonized Relocation Commandis sent back to the source Macro RNC 220, and a corresponding RRCmessage onward to the UE 200.

In accordance with one aspect of this embodiment, the local RAN GW 240unilaterally prepares a Reloc Request Ack and sends it to the targetERANs 250 a-n, along with the original Relocation Request. Theparameters contained within such a pre-configured Reloc Request Ackinform each of the target ERANs 250 a-n how to allocate resources for aradio bearer that may be established with the prospective UE (e.g., UE200) that is handing in to one of them. It should be noted that thispre-configured Reloc Request Ack uses resources that are pre-allocatedin each of the target ERANs 250 a-n.

In accordance with another aspect of this embodiment, and as analternative to utilizing a pre-configured Reloc Request Ack, RelocRequest Ack messages are synchronized to allow for the aforementionedharmonized Relocation Command to be sent to the Macro RNC 220.Accordingly, and upon receipt of a Relocation Request message from theCN 230, the local RAN GW 240 generates a pair of tokens, i.e., an“airlink” token and an “identifier” token. These tokens achieve the sameend goal of pre-configuring the Reloc Request Ack, but with theadvantage of keeping the local RAN GW 240 agnostic to the actuallower-layer mechanisms to do so. The complete content of the RelocRequest Ack is a function of both tokens. For example, the airlink andidentifier tokens may be concatenated, or alternatively, a hash functionmay be used to combine the airlink and identifier tokens. Those skilledin the art will understand that other combinations of the airlink andidentifier tokens are possible and are contemplated within the scope ofthe present invention.

The airlink token is tied to a specific configuration of airlinkresources. For example, a specific set of downlink and uplink scramblingcodes may be pre-reserved and tied to specific values of the airlinktoken. For each attempted hand-in, the local RAN GW 240 will use a newtoken from its airlink token pool. The configuration specified by thetoken is expected to be used only for a transient time intervalfollowing hand-in, as will be described in greater detail below.

The identifier token is used to pre-configure parameters such as theUMTS Terrestrial RAN (UTRAN) Radio Network Temporary Identifier(U-RNTI), which will remain in use for the life of the session followinghand-in, and will be released only upon a subsequent RRC ConnectionRelease, or a handover out of the local RAN, e.g.,ERAN. Therefore, thepool of these tokens is anticipated to be large, and unlike the airlinkresources, the parameters tied to the identifier token are notconstrained, and therefore there is no penalty attached to the size ofthis pool.

Once the pair of tokens is generated, the local RAN GW 240 multicaststhe Relocation Request message, along with the pair of tokens, to theset of target ERANs 250 a-n. Each target ERAN is able to allocate theappropriate resources based on the airlink token and the identifiertoken and return a Reloc Request Ack to the local RAN GW 240. Note thatthe configuration for a prospective inbound UE 200 is going to beidentical across all the ERANs that were sent the original RelocationRequest message.

Each target local RAN/ERAN 250 a-n will issue a Reloc Request Ackmessage to be sent back to the local RAN GW 240. In accordance with thefirst aspect of the embodiment relying upon pre-configured Reloc RequestAck messages, this is effectively an echo of the “canned” Reloc RequestAck that was initially sent by the local RAN GW 240 to each target ERAN250 a-n. In the case of the alternative token-based approach describedabove, each target ERAN 250 a-n has configured resources according tothe airlink and identifier tokens issued by the local RAN GW 240, andtherefore, generate identical Reloc Request Ack messages.

The local RAN GW 240 can simply wait for the first Reloc Request Ackmessage to arrive, and forward it to the Source/Macro RNC 220 that ispart of the macrocell network via the CN 230. The contents of the RBRmessage, or alternatively, an RRC message such as Physical ChannelReconfiguration (sent from the Source/Macro RNC 220 to the UE 200), thatis part of the Reloc Request Ack is, by design, guaranteed to match theresources reserved in each of the target ERANs 250 a-n.

The local RAN GW 240 may then simply drop all subsequent responses(e.g., 2^(nd)-N^(th) Reloc Acks from other target ERANs) after itforwards the first response back to the Source/Macro RNC 220.Alternatively, the local RAN GW 240 may choose to receive and subsumeeach subsequent message simply to keep track of the state of thecommunication with each target ERAN. In an alternative implementation,the target ERANs may internally allocate resources in response to aRelocation Request and never actually produce a Reloc Request Ack,deferring to the local RAN GW 240, which produces the RelocationResponse message unilaterally and sends it to the Source/Macro RNC 220.

Upon a successful hand-in, the hand-in procedure terminates when the UE200 manages to establish an RRC connection on one of the cells on one ofthe target ERANs 250 a-n, such as target ERAN 250 g (and ultimately, oneof target cells 260 a-m). At this point, the target ERAN 250 g can issuea Relocation Complete message to the local RAN GW 240, which indicatesthat it has acquired the inbound UE 200, pursuant to receiving an RBRComplete message from the UE 200. The local RAN GW 240 may then issue aRelocation Complete to the CN 230, and then proceed to clean up theresources on the other ERANs that were targeted in the initial multicastRelocation Request. This may be accomplished by sending out RelocationCancel messages to each of the target ERANs, other than the target ERAN250 g on/to which the hand-in was successful.

Additionally, since it is possible that multiple cells on the ERAN, withthe same PSC are participating in the handin of the UE, all cells otherthan the one that acquires the user would also be autonomously cleanedup by the target ERAN 250 g at this stage.

As discussed above, airlink resources are pre-reserved by the local RANGW on all cells that are participating in the handin through the use ofan airlink token. It may be problematic to reserve airlink resources inthis manner for the duration of a hand-in session due to the scarcity ofairlink resources and the volume of UE's that are likely to be handinginto a set of target ERANs in a small time interval. This problem isparticularly important when assigning downlink orthogonal variablespreading factor (OVSF) codes, and although partially mitigated by usingSecondary Scrambling Codes for the downlink, the reserved resourcesshould be freed up as quickly as possible so that the airlink tokenassociated with these resources can be freed up for reuse across the setof ERANs.

Accordingly, and to the above, the target ERAN may perform a PhysicalChannel Reconfiguration to move the UE from pre-reserved resources (thatare blocked across the set of target ERANs) to “internal airlinkresources,” which are independently managed by each target ERAN, and insome cases, on each cell. As soon as the Physical Channel Relocation iscomplete, the target ERAN can send a message to the local RAN GWindicating that the airlink token has been freed up and may be returnedto the pool for reuse.

As also noted above, the identifier token is tied to the U-RNTI and mayonly be cleaned up when the handed-in session terminates. At this point,a message is sent from the target RNC to the local RAN GW indicatingthat this token may also be returned to the identifier token pool forreuse.

An alternative approach to the use of Physical Channel Reconfigurationwould be to use procedures that can change the entire configuration tothe UE while retaining the UE on the same cell. An example of such aprocedure is the intra-nodeB hard handover procedure defined in the UMTSstandards. This approach may be completely localized within the targetERAN and performed after the UE has handed in. It should be noted thatthe requirement to use the identifier token is eliminated with thisalternative approach as the reconfiguration is intended to be performedsoon after hand-in, although a potential second outage may occur on thedata-plane of the user while this procedure is in progress.

FIG. 3 is a flow chart illustrating various processes that may beperformed from the perspective of a local RAN GW in accordance with oneembodiment of the present invention to achieve disambiguation of atarget cell in a local RAN, e.g., UMTS ERAN, deployment. At 300, arelocation request is received. As described above, the relocationrequest may be received by a local RAN GW from the CN in response to aSource/Macro RNC receiving a measurement report message identifying anERAN boundary PSC from a UE. At 310, the relocation request is multicastalong with a relocation request acknowledgement to multiple targetERANs. At 320, a first relocation acknowledgement may be received from afirst ERAN of the multiple target ERANs to which a UE is to be handedinto. At 330, the local RAN GW may forward that first relocationacknowledgement to the CN.

In accordance with another embodiment of the present invention, UEdetection by a target cell before handover may be leveraged todisambiguate the target cell for handover. That is, this embodiment ofthe present invention may be used by the combination of themacrocellular and ERAN networks to anticipate the target ERAN/cells thata UE is likely to handover to, and use this information to disambiguatethe target cell. In this regard, the target ERANs are made aware of theuplink configuration and timing of an incoming UE when it is stillconnected to the macrocellular network. For example, this informationmay be communicated to the target ERANs using a source-RNC-to-target-RNCtransparent container (“src-to-target RNC container”) that is availablein the Relocation Required message. It should be noted that thisinformation is optional in the current 3GPP standards specification, andthus may require a onetime configuration change for conventionalmacrocellular network elements.

In the case of interfrequency handover, the target cell needs to knowthe current uplink frequency used by the UE while attached to the macrocellular network. This information is typically not present in thesrc-to-target RNC container. This can either be signaled as avendor-specific extension or, alternatively, can be inferred by use ofthe src cell ID. The src cell IDS is present in the relocation requestmessage, and since a cell may be configured for use with a singlefrequency on the uplink, the target RNC can use a manual orautomatically generated look-up table to determine the frequency. Thelookup table may be automatically generated using any of a variety ofmethods, such as those described in U.S. patent application Ser. No.12/957,181, titled “METHOD, SYSTEM AND DEVICE FOR CONFIGURING TOPOLOGYOF A WIRELESS NETWORK,” filed Nov. 30, 2010, by “sniffing” the broadcastchannel of the macrocells apriori.

FIG. 4 is a flow chart illustrating exemplary processes performed inaccordance with this embodiment of the present application. In thisapproach, and at 400, the local RAN GW multicasts the uplink layerconfiguration of a UE to multiple target local RANs, such as ERANs. EachERAN may instruct a subset of the cells that it manages to attempt todetect the UE based on the uplink physical layer configuration. Thesubset may be restricted to the cells with the same PSC as reported bythe UE, some specially marked cells, or all cells that are managed bythe ERAN. At 410, if one or more of the multiple target ERANs detect thepresence of the UE, the one or more of the multiple target ERANs informthe local RAN GW of this detection, e.g., the local RAN GW receivesnotification of the detection of the presence of the UE from one or moreof the multiple target ERANs. This state information helps to localizethe UE and to reduce the scope of the multicast of the RelocationRequired message described above in accordance with the one embodimentof the present application. Thus, at 420, a relocation request is sentto only those ERANs that detected the presence of the UE. At 430, afirst relocation acknowledgement is received from a first ERAN of theone or more of the multiple target ERANs to which the UE is to be handedinto. At 440, as above, the first relocation acknowledgement isforwarded to a CN. If, however, none of the multiple target ERANs detectthe presence of the UE, the procedure merely defaults to the “full”multicast approach described above. Alternatively, if none of themultiple target ERANs detect the presence of the UE, the procedure couldterminate right away without attempting a hand-in.

From an implementation perspective, it should be noted that a processingchain would be allocated on each target cell to conduct such a searchper-UE. For inter-frequency deployments, in which ERANs are deployed indedicated channels, the radio nodes would use a separate second receiverto monitor the UTRA Absolute Radio Frequency Channel Number (ULARFCN) ofthe neighboring macrocells in order to perform UE detection.

In accordance with yet another embodiment of the present invention,information from the UE may be utilized to disambiguate a target cell orto limit the range of target ERANs to which Relocation Request messagesare multicast in a co-channel or dedicated channel deployment scenarios.For example, a UE-measured SFN-CFN observed timing difference or timingoffset may be utilized to disambiguate a target cell to effectuatehand-in.

Per the UMTS specifications, the timing offset is defined as:

Timing offset=chip offset*38400+frame offset,

and is measured relative to the connection frame number for the UEtransmission of an uplink DPCCH frame and the system frame number of thetarget cell P-CCPCH frame received in the UE. In case theinter-frequency measurement is done with compressed mode, the UE is notrequired to read the cell SFN of the target inter-frequency cell and thevalue for the parameter frame offset is always reported to be 0.

As described above, a source RNC initiates a handover by sending aRelocation Required message. The 3GPP standards specifications allow forthe inclusion of an optional information element covering a UEmeasurement report in a src-to-target RNC container of this message. Oneof the intended benefits from this inclusion is to allow the target RNCto instruct the target cell to set an appropriate level of initialdedicated traffic channel (DCH) transmit power based on the UE'smeasurements of the received power.

In a co-channel deployment, the UE will be able to send the timingdifference between a cell in its current active set and the target cellbeing reported in the measurement report in the form of a timing offsetfor all the cells that the UE measures. This would include the targetcell. The local RAN GW, which receives this transparent container, mayuse the timing information to disambiguate the target ERAN and thetarget cell. In order to disambiguate based on timing, it is desirablethat the reference clocks of all the ERANs and the macrocell network bein sync. However, even if the reference clocks are not in sync, a slowrelative drift may be accommodated by the local RAN GW through the useof mechanisms to periodically re-estimate the time difference betweencells relative to a master timing reference.

The local RAN GW can be made aware of the timing differences between thecells in each ERAN and the neighboring macrocells to disambiguate thetarget ERAN/cell. One way to accomplish this is for the ERANs to reporttiming differences measured during the radio environment monitoring(REM) process back to the local RAN GW. The timing differences reportedby the UE have a large range (4096 frames) and fine granularity(chip-level reports), and hence offer the potential to disambiguate thetarget ERAN and target cell with reasonable certainty, and withoutrequiring an elaborate timing sync mechanism between each individualERAN and the local RAN GW. Since this measurement is made periodically,if the relative timing drift between these measurements is less than ½of the temporal separation between 2 cells with the same PSC, the localRAN GW would be able to uniquely disambiguate the target ERAN. If thesame PSC is reused on multiple cells on the target ERAN, this processcan also be used to disambiguate the target cell.

While the various embodiments are described in the context of hardhandovers, use of such concepts in soft-handover contexts iscontemplated within the scope of the present invention. For example, invarious embodiments, the timing information may be used for target celldiscovery even if the source RNC already holds the PSC-to-cell IDmapping. For example, it is possible that the mapping includes multiplecells with the target PSC reported by the UE. In such a case, the timinginformation may be used to disambiguate a unique target cell fromamongst the cells with the identical PSC. Such a scenario is more likelyin deployments where there is a high density of PSC reuse within thesystem. This could include soft-handover within the same RNC or forinter-RNC soft-handover over an Iur link. Thus, the core gateway may notbe involved in the handover.

It should be noted that even if “perfect” disambiguation is not alwayspossible, the range of the targets for the multicast Relocation Requestmessages would still be reduced by utilizing the timing state containedwithin the local RAN GW.

In another embodiment, measurement reports from UEs may be used toaccomplish discovery of relative timing offsets between cells. Eachlocal RAN, such as an ERAN, will typically receive reports from UE'sconnected to the ERAN on the SFN-SFN timing differences reported againstexternal macrocells as well as neighboring ERANs. These reports can beused by each ERAN to send timing differences relative to cells ofanother ERAN or the macrocell back to the GW. The GW can aggregate thisinformation to update estimates of relative timing differences betweencells belonging to different local RANs.

In another embodiment, the GW may proactively configure a specifictiming offset range for each local RAN in order to facilitate PSCdisambiguation. Once again, the large range and granularity of timingavailable facilitates a local RAN GW instructing a specific ERAN toposition the system frame number (SFN) offsets of its cell with respectto specific neighboring macrocells in a pre-configured manner. Forexample, a particular ERAN may be instructed to configure its cellswithin “N” frames of the SFN boundary of a specific macrocell that atleast one of the ERAN cells is able to measure. This pre-configurationof ERAN timing allows further disambiguation of the target ERAN/cell bythe local RAN GW in the event of an inbound Relocation Request message.

Since each ERAN would be required to register with the local RAN GWeither periodically or upon system reboot/initialization, the local RANGW may provide an updated configuration each time to maximize timingseparation between ERANs and therefore to minimize ambiguity in targetERANs/Cells. This is to accommodate the natural timing drift that occursbetween clocks that are unsynchronized between the local RAN GW and theindividual ERANs.

In yet another embodiment, the local RAN GW may forward/multicast thetiming information to all the ERANs and the ERANs could make anautonomous decision regarding whether to participate in the hand-inand/or the subset of cells in the ERAN that participate in the hand-in.In this case, the local RAN GW need not maintain the timing informationfor the cells on the ERAN. Thus, the ability to use of timinginformation may be distributed to the various ERANs.

The above concepts may also be applicable to dedicated channeldeployments. In this case, the UE does not report the frame offset, butwould still report the chip offset. The chip offsets cover a very narrowspan of 10 ms, so much “tighter” timing synchronization would berequired. However, if recent UE measurement reports are available fromUEs within the system, this concept can be used to reduce the number ofcells and/or the number of ERANs that participate in the hand-inprocess. This embodiment may be implemented in dedicated channeldeployments, as well as in co-channel deployments.

The restriction of local RANs/ERANs and Cells that participate in thehand-in process can happen either at the local RAN GW, or if the GWsupports the multicast framework described above, could also happen atthe target ERAN.

In various other embodiments, information from the UE other than timingoffset information may be used for disambiguation purposes. Themeasurement report from the UE includes, for example, thesignal-to-noise ratio (SNR), received signal code power (RSCP) andpathloss of the pilot signal broadcast by the various target cells. Invarious embodiments, the local RAN gateway may use this information tolimit the range of target ERANs to which Relocation Request messages aremulticast.

FIG. 5 is a flow chart illustrating various processes performed inaccordance with an embodiment of the present application. At 500, timinginformation may be received in a measurement report message from a UE,where the timing information is associated with a local RAN, such as anERAN, cell that the UE wants to hand-in to. For example, and asdiscussed above, the measurement report may be received at an local RANGW from a UE. At 510, the local RAN GW utilizes the timing informationreceived from the UE to disambiguate at least one target ERAN and cellfrom a plurality of ERANs and cells, where the at least one target ERANand cell include/encompass the desired ERAN cell to which the UE wantsto hand-in. For example, and as also discussed above, the local RAN GWmay receive the timing differences between the macrocells and the cellsin each ERAN during a REM process, or pre-configured timing offsets. At520, as in accordance with other embodiments, a relocation request issent to the at least one disambiguated target ERAN and cell. At 530, arelocation acknowledgement is received from the desired ERAN cell towhich a UE is to be handed into. At 540, the relocation acknowledgementis forwarded to the CN.

While various embodiments of the present invention have been describedabove for a WCDMA UMTS system, it should be understood that they havebeen presented by way of example only, and not of limitation. Likewise,the various diagrams may depict an example architectural or otherconfiguration for the invention, which is done to aid in understandingthe features and functionality that can be included in the invention.The invention is not restricted to the illustrated example architecturesor configurations, but the desired features can be implemented using avariety of alternative architectures and configurations. Indeed, it willbe apparent to one of skill in the art how alternative functional,logical or physical partitioning and configurations can be implementedto implement the desired features of the present invention. Also, amultitude of different constituent module names other than thosedepicted herein can be applied to the various partitions. Additionally,with regard to flow diagrams, operational descriptions and methodclaims, the order in which the steps are presented herein shall notmandate that various embodiments be implemented to perform the recitedfunctionality in the same order unless the context dictates otherwise.

Although the invention is described above in terms of various exemplaryembodiments and implementations, it should be understood that thevarious features, aspects and functionality described in one or more ofthe individual embodiments are not limited in their applicability to theparticular embodiment with which they are described, but instead can beapplied, alone or in various combinations, to one or more of the otherembodiments of the invention, whether or not such embodiments aredescribed and whether or not such features are presented as being a partof a described embodiment. Thus, the breadth and scope of the presentinvention should not be limited by any of the above-described exemplaryembodiments.

Terms and phrases used in this document, and variations thereof, unlessotherwise expressly stated, should be construed as open ended as opposedto limiting. As examples of the foregoing: the term “including” shouldbe read as meaning “including, without limitation” or the like; the term“example” is used to provide exemplary instances of the item indiscussion, not an exhaustive or limiting list thereof; the terms “a” or“an” should be read as meaning “at least one,” “one or more” or thelike; and adjectives such as “conventional,” “traditional,” “normal,”“standard,” “known” and terms of similar meaning should not be construedas limiting the item described to a given time period or to an itemavailable as of a given time, but instead should be read to encompassconventional, traditional, normal, or standard technologies that may beavailable or known now or at any time in the future. Likewise, wherethis document refers to technologies that would be apparent or known toone of ordinary skill in the art, such technologies encompass thoseapparent or known to the skilled artisan now or at any time in thefuture.

The presence of broadening words and phrases such as “one or more,” “atleast,” “but not limited to” or other like phrases in some instancesshall not be read to mean that the narrower case is intended or requiredin instances where such broadening phrases may be absent. The use of theterm “module” does not imply that the components or functionalitydescribed or claimed as part of the module are all configured in acommon package. Indeed, any or all of the various components of amodule, whether control logic or other components, can be combined in asingle package or separately maintained and can further be distributedin multiple groupings or packages or across multiple locations.

Additionally, the various embodiments set forth herein are described interms of exemplary block diagrams, flow charts and other illustrations.As will become apparent to one of ordinary skill in the art afterreading this document, the illustrated embodiments and their variousalternatives can be implemented without confinement to the illustratedexamples. For example, block diagrams and their accompanying descriptionshould not be construed as mandating a particular architecture orconfiguration.

Moreover, various embodiments described herein are described in thegeneral context of method steps or processes, which may be implementedin one embodiment by a computer program product, embodied in acomputer-readable memory, including computer-executable instructions,such as program code, executed by computers in networked environments. Acomputer-readable memory may include removable and non-removable storagedevices including, but not limited to, Read Only Memory (ROM), RandomAccess Memory (RAM), compact discs (CDs), digital versatile discs (DVD),etc. Generally, program modules may include routines, programs, objects,components, data structures, etc. that perform particular tasks orimplement particular abstract data types. Computer-executableinstructions, associated data structures, and program modules representexamples of program code for executing steps of the methods disclosedherein. The particular sequence of such executable instructions orassociated data structures represents examples of corresponding acts forimplementing the functions described in such steps or processes. Variousembodiments may comprise a computer-readable medium including computerexecutable instructions which, when executed by a processor, cause anapparatus to perform the methods and processes described herein.

Furthermore, embodiments of the present invention may be implemented insoftware, hardware, application logic or a combination of software,hardware and application logic. The software, application logic and/orhardware may reside on a client device, a server or a network component.If desired, part of the software, application logic and/or hardware mayreside on a client device, part of the software, application logicand/or hardware may reside on a server, and part of the software,application logic and/or hardware may reside on a network component. Inan example embodiment, the application logic, software or an instructionset is maintained on any one of various conventional computer-readablemedia. In the context of this document, a “computer-readable medium” maybe any media or means that can contain, store, communicate, propagate ortransport the instructions for use by or in connection with aninstruction execution system, apparatus, or device, such as a computer.A computer-readable medium may comprise a computer-readable storagemedium that may be any media or means that can contain or store theinstructions for use by or in connection with an instruction executionsystem, apparatus, or device, such as a computer. In one embodiment, thecomputer-readable storage medium is a non-transitory storage medium.

What is claimed is:
 1. A method, comprising: receiving a measurementreport, the measurement report containing information from a userequipment, the information being associated with a desired local RadioAccess Network (RAN) cell to which the user equipment is to hand-in; andutilizing the information in the measurement report to disambiguate atleast one target local RAN and cell from a plurality of local RANs andcells, the at least one target local RAN and cell including the desiredlocal RAN cell.
 2. The method of claim 1, wherein the measurement reportis received at a local RAN gateway from a source RAN.
 3. The method ofclaim 2, further comprising: receiving, at the local RAN gateway, arelocation required message from a source RAN, the relocation requiredmessage containing the measurement report; sending a relocation requestto the at least one disambiguated target local RAN and cell; receiving arelocation acknowledgement from the desired local RAN cell; andforwarding the relocation acknowledgement to a core network.
 4. Themethod of claim 3, further comprising: receiving at the local RANgateway from the plurality of local RANs and cells, timing informationrelating to timing differences between the cells of the plurality oflocal RANs and cells and neighboring cells measured during a radioenvironment monitoring process.
 5. The method of claim 4, furthercomprising: periodically updating the timing difference information. 6.The method of claim 1, wherein the information in the measurement reportused to disambiguate at least one target local RAN and cell is a timinginformation associated with the desired RAN cell.
 7. The method of claim6, wherein the timing information includes a timing difference between acell in the current active set of the user equipment and the desired RANcell.
 8. The method of claim 6, wherein the timing information includesa chip offset of the desired RAN cell.
 9. The method of claim 6, furthercomprising: multicasting the received timing information to theplurality of local RANs and cells, wherein each of the plurality oflocal RANs and cells autonomously determines whether to at least one ofparticipate in the handover or restrict the plurality of cells that areto participate in the handover.
 10. The method of claim 1, furthercomprising: configuring a specific timing offset range for each of theplurality of local RANs and cells.
 11. The method of claim 10, whereinthe specific timing offset range is configured by a local RAN gateway asa part of a gateway registration process.
 12. The method of claim 1,utilizing the information comprising: disambiguating the target localRAN and cell based on the information in the measurement report andtiming information relating the target local RAN and cell.
 13. Themethod of claim 12, wherein the utilizing of the information todisambiguate the target local RAN and cell is performed at a source RAN.14. The method of claim 13, further comprising: determining, by thesource RAN, a desired local cell within a current RAN; and performing asoft handover without involving a local RAN gateway of the current RAN.15. The method of claim 13, further comprising: determining, by thesource RAN that a desired local RAN and cell belongs to a second localRAN linked to a current local RAN via an Iur link; and performing a softhandover over the Iur link without involving a local RAN gateway of thecurrent local RAN.
 16. The method of claim 1, wherein the information inthe measurement report used to disambiguate at least one target localRAN and cell is a signal-to-noise ratio (SNR) of a pilot signalbroadcast by the desired RAN cell.
 17. The method of claim 1, whereinthe information in the measurement report used to disambiguate at leastone target local RAN and cell is a received signal code power (RSCP) ofa pilot signal broadcast by the desired RAN cell.
 18. The method ofclaim 1, wherein the information in the measurement report used todisambiguate at least one target local RAN and cell is a pathloss of apilot signal broadcast by the desired RAN cell.
 19. A method,comprising: receiving, at one of a plurality of local Radio AccessNetworks (RANs), a multicast message from a local RAN gateway, themulticast message including timing information related to each of theplurality of local RANs, the plurality of local RANs being candidatesfor a hand-in of a user equipment; and determining, by the one of theplurality of local RANs, whether to at least one of participate in thehandover or restrict the plurality of cells that are to participate inthe handover, based on the timing information.
 20. An apparatus,comprising: a processor; and a memory including computer program code,the memory and the computer program code configured to, with theprocessor, cause the apparatus to perform at least the following:receive a measurement report, the measurement report containinginformation from a user equipment, the information being associated witha desired local Radio Access Network (RAN) cell to which the userequipment is to hand-in; and utilize the information in the measurementreport to disambiguate at least one target local RAN and cell from aplurality of local RANs and cells, the at least one target local RAN andcell including the desired local RAN cell.
 21. An apparatus, comprising:a processor; and a memory including computer program code, the memoryand the computer program code configured to, with the processor, causethe apparatus to perform at least the following: receive, at one of aplurality of local Radio Access Networks (RANs), a multicast messagefrom a local RAN gateway, the multicast message including timinginformation related to each of the plurality of local RANs, theplurality of local RANs being candidates for a hand-in of a userequipment; and determine, by the one of the plurality of local RANs,whether to at least one of participate in the handover or restrict theplurality of cells that are to participate in the handover, based on thetiming information.
 22. A computer program product, embodied on anon-transitory computer-readable medium, comprising: computer code forreceiving a measurement report, the measurement report containinginformation from a user equipment, the information being associated witha desired local Radio Access Network (RAN) cell to which the userequipment is to hand-in; and computer code for utilizing the informationin the measurement report to disambiguate at least one target local RANand cell from a plurality of local RANs and cells, the at least onetarget local RAN and cell including the desired local RAN cell.
 23. Acomputer program product, embodied on a non-transitory computer-readablemedium, comprising: computer code for receiving, at one of a pluralityof local Radio Access Networks (RANs), a multicast message from a localRAN gateway, the multicast message including timing information relatedto each of the plurality of local RANs, the plurality of local RANsbeing candidates for a hand-in of a user equipment; and computer codefor determining, by the one of the plurality of local RANs, whether toat least one of participate in the handover or restrict the plurality ofcells that are to participate in the handover, based on the timinginformation.